home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc2245.txt < prev   
Text File  |  1997-12-07  |  10KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          C. Newman
  8. Request for Comments: 2245                                      Innosoft
  9. Category: Standards Track                                  November 1997
  10.  
  11.  
  12.                         Anonymous SASL Mechanism
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  25.  
  26. Abstract
  27.  
  28.    It is common practice on the Internet to permit anonymous access to
  29.    various services.  Traditionally, this has been done with a plain
  30.    text password mechanism using "anonymous" as the user name and
  31.    optional trace information, such as an email address, as the
  32.    password.  As plaintext login commands are not permitted in new IETF
  33.    protocols, a new way to provide anonymous login is needed within the
  34.    context of the SASL [SASL] framework.
  35.  
  36. 1. Conventions Used in this Document
  37.  
  38.    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  39.    in this document are to be interpreted as defined in "Key words for
  40.    use in RFCs to Indicate Requirement Levels" [KEYWORDS].
  41.  
  42. 2. Anonymous SASL mechanism
  43.  
  44.    The mechanism name associated with anonymous access is "ANONYMOUS".
  45.    The mechanism consists of a single message from the client to the
  46.    server.  The client sends optional trace information in the form of a
  47.    human readable string.  The trace information should take one of
  48.    three forms: an Internet email address, an opaque string which does
  49.    not contain the '@' character and can be interpreted by the system
  50.    administrator of the client's domain, or nothing.  For privacy
  51.    reasons, an Internet email address should only be used with
  52.    permission from the user.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Newman                      Standards Track                     [Page 1]
  59.  
  60. RFC 2245                Anonymous SASL Mechanism           November 1997
  61.  
  62.  
  63.    A server which permits anonymous access will announce support for the
  64.    ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
  65.    usually with restricted access.
  66.  
  67.    The formal grammar for the client message using Augmented BNF [ABNF]
  68.    follows.
  69.  
  70.    message         = [email / token]
  71.  
  72.    TCHAR           = %x20-3F / %x41-7E
  73.                      ;; any printable US-ASCII character except '@'
  74.  
  75.    email           = addr-spec
  76.                      ;; as defined in [IMAIL], except with no free
  77.                      ;; insertion of linear-white-space, and the
  78.                      ;; local-part MUST either be entirely enclosed in
  79.                      ;; quotes or entirely unquoted
  80.  
  81.    token           = 1*255TCHAR
  82.  
  83. 3. Example
  84.  
  85.  
  86.    Here is a sample anonymous login between an IMAP client and server.
  87.    In this example, "C:" and "S:" indicate lines sent by the client and
  88.    server respectively.  If such lines are wrapped without a new "C:" or
  89.    "S:" label, then the wrapping is for editorial clarity and is not
  90.    part of the command.
  91.  
  92.    Note that this example uses the IMAP profile [IMAP4] of SASL.  The
  93.    base64 encoding of challenges and responses, as well as the "+ "
  94.    preceding the responses are part of the IMAP4 profile, not part of
  95.    SASL itself.  Newer profiles of SASL will include the client message
  96.    with the AUTHENTICATE command itself so the extra round trip below
  97.    (the server response with an empty "+ ") can be eliminated.
  98.  
  99.    In this example, the user's opaque identification token is "sirhc".
  100.  
  101.         S: * OK IMAP4 server ready
  102.         C: A001 CAPABILITY
  103.         S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
  104.         S: A001 OK done
  105.         C: A002 AUTHENTICATE ANONYMOUS
  106.         S: +
  107.         C: c2lyaGM=
  108.         S: A003 OK Welcome, trace information has been logged.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Newman                      Standards Track                     [Page 2]
  115.  
  116. RFC 2245                Anonymous SASL Mechanism           November 1997
  117.  
  118.  
  119. 4. Security Considerations
  120.  
  121.    The anonymous mechanism grants access to information by anyone.  For
  122.    this reason it should be disabled by default so the administrator can
  123.    make an explicit decision to enable it.
  124.  
  125.    If the anonymous user has any write privileges, a denial of service
  126.    attack is possible by filling up all available space.  This can be
  127.    prevented by disabling all write access by anonymous users.
  128.  
  129.    If anonymous users have read and write access to the same area, the
  130.    server can be used as a communication mechanism to anonymously
  131.    exchange information.  Servers which accept anonymous submissions
  132.    should implement the common "drop box" model which forbids anonymous
  133.    read access to the area where anonymous submissions are accepted.
  134.  
  135.    If the anonymous user can run many expensive operations (e.g., an
  136.    IMAP SEARCH BODY command), this could enable a denial of service
  137.    attack.  Servers are encouraged to limit the number of anonymous
  138.    users and reduce their priority or limit their resource usage.
  139.  
  140.    If there is no idle timeout for the anonymous user and there is a
  141.    limit on the number of anonymous users, a denial of service attack is
  142.    enabled.  Servers should implement an idle timeout for anonymous
  143.    users.
  144.  
  145.    The trace information is not authenticated so it can be falsified.
  146.    This can be used as an attempt to get someone else in trouble for
  147.    access to questionable information.  Administrators trying to trace
  148.    abuse need to realize this information may be falsified.
  149.  
  150.    A client which uses the user's correct email address as trace
  151.    information without explicit permission may violate that user's
  152.    privacy.  Information about who accesses an anonymous archive on a
  153.    sensitive subject (e.g., sexual abuse) has strong privacy needs.
  154.    Clients should not send the email address without explicit permission
  155.    of the user and should offer the option of supplying no trace token
  156.    -- thus only exposing the source IP address and time.  Anonymous
  157.    proxy servers could enhance this privacy, but would have to consider
  158.    the resulting potential denial of service attacks.
  159.  
  160.    Anonymous connections are susceptible to man in the middle attacks
  161.    which view or alter the data transferred.  Clients and servers are
  162.    encouraged to support external integrity and encryption mechanisms.
  163.  
  164.    Protocols which fail to require an explicit anonymous login are more
  165.    susceptible to break-ins given certain common implementation
  166.    techniques.  Specifically, Unix servers which offer user login may
  167.  
  168.  
  169.  
  170. Newman                      Standards Track                     [Page 3]
  171.  
  172. RFC 2245                Anonymous SASL Mechanism           November 1997
  173.  
  174.  
  175.    initially start up as root and switch to the appropriate user id
  176.    after an explicit login command.  Normally such servers refuse all
  177.    data access commands prior to explicit login and may enter a
  178.    restricted security environment (e.g., the Unix chroot function) for
  179.    anonymous users.  If anonymous access is not explicitly requested,
  180.    the entire data access machinery is exposed to external security
  181.    attacks without the chance for explicit protective measures.
  182.    Protocols which offer restricted data access should not allow
  183.    anonymous data access without an explicit login step.
  184.  
  185. 5. References
  186.  
  187.    [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
  188.    Specifications: ABNF", RFC 2234, November 1997.
  189.  
  190.    [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
  191.    Messages", STD 11, RFC 822, August 1982.
  192.  
  193.    [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
  194.    4rev1", RFC 2060, December 1996.
  195.  
  196.    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
  197.    Requirement Levels", RFC 2119, March 1997.
  198.  
  199.    [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
  200.    RFC 2222, October 1997.
  201.  
  202. 6. Author's Address
  203.  
  204.    Chris Newman
  205.    Innosoft International, Inc.
  206.    1050 Lakes Drive
  207.    West Covina, CA 91790 USA
  208.  
  209.    Email: chris.newman@innosoft.com
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Newman                      Standards Track                     [Page 4]
  227.  
  228. RFC 2245                Anonymous SASL Mechanism           November 1997
  229.  
  230.  
  231. 7.  Full Copyright Statement
  232.  
  233.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  234.  
  235.    This document and translations of it may be copied and furnished to
  236.    others, and derivative works that comment on or otherwise explain it
  237.    or assist in its implementation may be prepared, copied, published
  238.    and distributed, in whole or in part, without restriction of any
  239.    kind, provided that the above copyright notice and this paragraph are
  240.    included on all such copies and derivative works.  However, this
  241.    document itself may not be modified in any way, such as by removing
  242.    the copyright notice or references to the Internet Society or other
  243.    Internet organizations, except as needed for the purpose of
  244.    developing Internet standards in which case the procedures for
  245.    copyrights defined in the Internet Standards process must be
  246.    followed, or as required to translate it into languages other than
  247.    English.
  248.  
  249.    The limited permissions granted above are perpetual and will not be
  250.    revoked by the Internet Society or its successors or assigns.
  251.  
  252.    This document and the information contained herein is provided on an
  253.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  254.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  255.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  256.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  257.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Newman                      Standards Track                     [Page 5]
  283.  
  284.